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STACK OVERFLOW 


= Anti-Patterns: 
e No worst case stack size analysis 
e Use of recursion 
e No memory protection for stack 


= The stack stores data for subroutines 
e Automatic (non-static) variables 
— Also, subroutine & interrupt register saves 
e Calls put data on stack 
— Interrupts & RTOS calls put data on stack too 
e But what if the stack overflows? 
— Need to handle worst-case stack size 
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Stack Overflow Corrupts Memory 5 as 


= If stack gets too big, it stomps on other =MEMORY 
SPACE 


memory: Stack Overflow 
e Can corrupt static variables and globals 
e Can corrupt RTOS data structures 


INCORRECT 
— System-wide task information corruption STACK SIZE 
OR 
EXCESSIVE 
m Can cause system crashes RECURSION 
e Worse, can cause subtle system te 7 
corruption OVERFLOW 


— Task death, task period alteration 
— Security exploits via access to OS data 
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= Preferred approaches: 
e Static analysis of stack depth 
— Tool can figure out maximum depth 
— MMU hardware memory protection 


= At Run-Time: Stack Sentinels 
e At system start, fill stack with a 
sentinel value (e.g., OxAA44CC33) 
e Program execution writes to stack 
— Sentinels permanently overwritten 


e Periodically check to see how many 
sentinels are left (stack size margin) 
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Prevent & Detect Stack Overflow TS Pas, 
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Best Practices For Avoiding Stack Overflow Mellon 


University 





= Determine worst case stack depth 
e Sentinels are a good start 
— But you might not see true worst-case depth in testing 
- Worst-case stack depth for deeply nested calls + safety margin 
e Use a tool if you have one, or use a disassembler 
— PLUS: Biggest interrupt service routine stack use 
— PLUS: RTOS call use of stack (can be significant) 
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m= Protect stack at run time 
e Use MMU hardware protection if you have it 


e Use sentinels & periodic check to detect stack overflow 
— Also helps with experimental confirmation of depth analysis 
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= Avoid recursion — makes worst case problematic 


e Be mindful that big data structures can make stack big Ne ve tole: 
ilip Koopman 


THE #7 PROGRAMMER EXCUSE 
FOR LEGITIMATELY SLACKING OFF: 


“MY CODE’S COMPILING.” 


“HEY! 1 TINK .— 
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